IBIS Macromodel Task Group

Meeting date: 17 May 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
SAE ITC                       Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to send BIRD213.1 draft 24 to the ATM list.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 10th
meeting.  Ambrish moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

PAMn BIRD 213.1 draft 24:
The group resumed discussion of the PAM_Offsets Usage Rules.  Fangyi noted that
he had replied to Arpad's draft 24 email and provided a table summarizing the
rules for statistical flow for the various combinations of parameter values.
One correction to the table was noted:  Rx_Decision_Time overrides
Rx_Clock_Recovery_Mean (per the IBIS 7.1 Usage Rules for Rx_Decision_Time).  So,
if Rx_Decision_Time is specified for NRZ it is not added to
Rx_Clock_Recovery_Mean (it replaces it).

Walter referred to the last two sentences of PAM_Offsets Usage Rules (draft 24):
  Note: When Modulation_Levels is defined and is not equal to 2,
  Rx_Clock_Recovery_Mean is ignored.  The offset described by
  Rx_Clock_Recovery_Mean should be included in PAM_Offsets.
and said the phrase "should be included" was confusing.

Walter suggested replacing the last paragraph with an enumerated list of the
various combinations of Modulation_Levels value and Rx_Decision_Time's presence
or absence.  Walter took an AR to draft the enumerated list and proposed changes
to the BIRD.  Randy noted that page 213 of IBIS 7.1 contained an example of
formatting for such an enumerated list.  Ambrish asked whether this information
should be repeated in the Rx_Decision_Time Usage Rules as well.

Walter noted that PAM_Offsets is an output for statistical (AMI_Init) and time
domain (AMI_GetWave).  He asked what a model should do if it only wants to use
it in time domain.  Fangyi and Curtis said the model could returns zero(s) from
AMI_Init.

In an earlier email, Arpad had noted an additional section on page 280 that
might need changes.  At the end of the PAM4_Mapping parameter's Other Notes
section is a two-item list headlined with the sentence:
  There are two reasons why a mapping is required.
Arpad said this sentence is no longer true, since we don't require or provide
a mapping with the new Modulation_Levels approach.  Walter suggested simply
replacing the word "mapping" with "PAM4_Mapping".  Curtis suggested we also
change "is required" to "is used."  The group settled on:
  There are two reasons why PAM4_Mapping might be used.
Ambrish then asked whether we need this sentence at all.  Do we have to explain
the reasons one might use PAM4_Mapping?

MIPI C-PHY - Do we need changes in IBIS:
Arpad started a discussion about whether we need to enhance the legacy IBIS
buffer keywords to deal with MIPI C-PHY.  He presented some schematic overviews
of the MIPI C-PHY interface.

Walter said each lane of MIPI C-PHY consists of 3 lines.  Each of those lines
is essentially a single-ended PAM3.  The lines might have separate delays, etc.,
but the EDA tool could run 3 single-ended AMI simulations to the far end.  There
are rules about which combinations of levels are allowed on the 3 lines at a
given time, but the EDA tool could control the stimulus input to the 3 PAM3
channel simulations to ensure compliance with those rules.

Fangyi observed that the three driver states shown in Arpad's original schematic
overview were 50 Ohms to one rail, 50 Ohms to the other rail, and 100 Ohms to
each rail.  We end up with a voltage source with 50 Ohm impedance, and the
voltage source has 3 levels.  IBIS could handle the 3 levels by varying the VCC.
IBIS really only cares about the I/V curves.

Arpad said AMI simulations were one thing, but they involve an LTI assumption.
He asked whether we might need to enhance the keywords for non-AMI IBIS so we
could address the MIPI C-PHY architecture and deal with non-linear effects like
PDNs and modulation from supply effects.  Walter said the question was whether
we want to do any of this.

- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Arpad to send BIRD213.1 draft 25 to the ATM list.
AR: Walter to alter draft 25 by creating a list of combinations and behaviors
    for PAM_Offsets Usage Rules.
    
-------------
Next meeting: 24 May 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
